The procurement and provisioning of a wireless application on an electronic device is a complex multi-step process that can be both time-consuming and expensive and further presents a significant obstacle to the large-scale deployment of complex wireless devices and services within organizations. By way of illustration, reference is made to FIG. 1, which shows a flow diagram for a conventional method typically used by the member of an organization to procure and provision one or more wireless applications. Beginning in step (1), a member of an organization (or someone acting on behalf of the member) conducts research on the mobile devices and then purchases a device. Furthermore, a new service plan for the device is activated. (Alternatively, an existing service plan may be transferred to the purchased device). The member procures a mobile device compatible with the desired applications by using one of several different methods (e.g., going to a retail store, ordering on-line via the Internet, etc.). In step (2), after the member purchases the device, the member then selects and acquires client applications to be executed on the newly procured device.
In step (3), the member (or an application administrator within the organization) installs any client software needed to support the desired application(s). Generally, the member (or third party acting on behalf of that member who will install the client-side software) then provides information regarding the device and the client application software to the application administrator so that the application administrator can perform provisioning on the server side to support the newly installed application(s) (step (4)). In some instances, this may entail physically handing the device to the application administrator for server-side provisioning. Once the server-side provisioning is completed in step (5), the device (with the client application(s) installed) is returned to the member. Next, in step (6), the member undergoes training on how to use the newly installed application. Finally, the application is available for use by the member (step (7)).
Reference is now made to FIGS. 2A-2B, which is a flow diagram illustrating another conventional method for procuring and provisioning wireless applications. Beginning in block 202, a device capable of supporting the desired application(s) is first requested by a member. Furthermore, a service plan is selected. In block 204, a determination is made on whether or not the member already has available the desired service (e.g., carrier circuit switched voice service, carrier data transport services, local area services). If the member does not have the service, then the new service will be requested and the service will be activated for the requested device in block 206. However, if the member already has the desired service, then that service will be transferred to the requested device in block 208.
In block 210, the device is received by the member, and in block 212 a determination is made on whether the member or someone acting on behalf of the member (e.g., a contractor hired by the organization to perform such work, a network administrator, a support person in the organization, an application) must install the application(s). If the member does not need to install the application(s), then in block 214, the member delivers the device to appropriate third party. Alternately, the device can be delivered directly to the appropriate third party, assuming that the member knows who the third party is a priori and has their delivery information (e.g., address). The third party may be an application administrator within the organization, for example. If the application(s) must be installed, then in block 216, any license(s) associated with the software or service required for the application(s) is acquired. In block 218, a determination is made on whether the procured device will actually support the selected application(s). If it is determined that the device cannot support the application(s) due to operating system incompatibility or insufficient memory, for instance, then the device is returned back to the party from which it was acquired (block 220), and the member must restart the process again with a new device.
Reference is made to FIG. 2B, beginning at node A. If the device is capable of supporting the desired application(s), then in block 222, the one or more applications are installed on the device and configured as needed to operate with the appropriate services. If the application(s) requires a corresponding server to operate (e.g., the application is a client-server based application), then in block 224 the application is installed and configured on the corresponding server by the appropriate party. Once the application(s) is fully installed and configured, the application(s) is tested in block 226.
In decision block 228, a determination is made on whether the application(s) was properly installed by a member of the organization. If the application(s) was not installed by a member, then in block 230, the device is returned back to the member without the application(s) installed as an unauthorized installation was attempted. If the application(s) was installed by a member, the member is trained on the use of the application in block 232. Finally, in block 234, other administrative functions associated with the procurement and provisioning of applications such as financial accounting of costs associated with the device, costs for service activation, and costs for the installation of application(s) (e.g., client access licenses) are completed.
As seen from FIGS. 1 and 2A-2B, conventional approaches by which organizations procure and provision wireless applications is generally inefficient and has the potential for error. For example, if the member fails to perform adequate research to determine the compatibility of the device with the application(s) to be installed, the member may potentially purchase an incompatible device. If this occurs, the incompatible device must be returned for a compatible one. A compatible device will then have to be procured and provisioned. As another example, once a compatible device is procured, the member may need to acquire client software needed to support the device and then install this software. The member must coordinate the provisioning of the device with the server software with the application administrator in order to affect the end-to-end provisioning of the application. Depending upon the workload of the administrator, a significant period of time can pass before the request is completed. Finally, another apparent shortcoming is that a member might need to acquire the necessary training materials and/or arrange for the necessary training in order to use the applications installed on the device.
Thus, a perceived shortcoming with conventional approaches is that methods currently used by telecom and IT departments within organizations to procure and provision such wireless applications are complex, time-consuming, and expensive. Furthermore, the burden of procuring and provisioning falls on the procurer (i.e., member or someone acting on behalf of the member) and the administrator. Consequently, conventional methods represent a significant impediment to large-scale deployment of wireless applications. Therefore, there is a need in the industry to overcome these deficiencies and inadequacies of current wireless application deployment methods to better streamline the process of procuring and provisioning these wireless applications.